Patrick Elliott wrote:
> In article <41d6ae1a$1@news.povray.org>, Sil### [at] gmxde says...
> 
>>Thorsten Froehlich wrote:
>>But POVRay 
>>files are rather small. Parsing speed does not matter that much.
>>
> 
> Ah.. A real professional user of POV-Ray are we? Some SDL takes longer to 
> parse than the actually rendering. The very idea that size, complexity 
> and speed in that step is irrelevant is.... incomprehensible..

To be honest: I am not a professional user of POVRay. I just want to 
render some illustrations for my documents and my webpage with POVRay. 
No landscapes, no complex meshes and so on. The sentence you quoted lost 
its context: In MPEG parsing speed is essential. It can make the 
difference if you can watch a movie on a 300Mhz processor or if you need 
a 1000Mhz processor. Assembler optimization is absolutely neccessary for 
such parsers. But in POVRay its different: There is no time limitation 
of that kind. You don't render 25 pics per second, do you? So what if 
you need twice the time for parsing? It won't do that much harm. You 
just have to wait a bit longer or buy a faster computer or simplify your 
scene a bit.

Besides: Parsing is just transforming the program to a treelike internal 
representation form. It's not executing or evaluating the program except 
you do everything with the preprocessor. So does it really take that 
long to process handwritten code? I cannot believe that. It will take 
much longer to execute and evaluate the internal treelike representation.

>>Now for the 4.0 rewrite: What will it be like? I just googled a bit, but 
>>I couldn't find anything about it. How do you know that similar 
>>limitations like the ones described won't appear again? Is there any 
>>information about it available?
>>
> 
> First off... Thorsten Froehlich is on the development team for this 
> program, so one would think he would have a clue what the flaws are and 
> why your idea is purely nuts. Yeah, there is one application of XML I can 
> think of that provides for programming, but it does so by borrowing the 
> <script></script> tags from HTML and using real languages to do the work. 
> The rest of it is just parsing of user readable information that defines 
> simple behaviours and settings for inbuilt functions, not complex 
> objects. It also uses name spaces to keep things straight, but doesn't 
> allow directly talking between things in different name spaces. Why? 
> Because the same 'include' might be used in several different XML 
> plugins. Each of them could use the same function names, the same names 
> for objects, etc. and keeping all of them straight, even with namespaces, 
> is easier is they never directly interface in any way. The interfaces 
> that are supported involve using a unique UID for each one, to make sure 
> they don't interfere. With POV-Ray, even with separate spaces, these 
> things have to interoperate and coexist. That has to be handled 'by the 
> application'.
> 
> What form the data takes in the source file has nothing to do with the 
> function, only the time wasted a) coding it and b) parsing it. Making it 
> intentionally more complex doesn't fix the problem, which is not in the 
> file, but in the way the application handles the information. You could 
> use bloody Sanskrit on punch cards, Tolkein's elven language transmitted 
> by brain waves or even your XML idea and it wouldn't alter the fact that 
> the problem is in the limitation of how the data is handled 'in the 
> program', not how it is represented in the SDL itself.

Right. That is why I suggest to put some processing outside of POVRay. 
POVRay is a good raytracer. I'm really impressed by it's fine 
performance. But I think that not all processing of data should be done 
by POVRay. There are e.g. programs that build meshes out of other data. 
A good example might be the creation of humanoids out of a collection of 
sizes. I will never be able to write anything like human{<0,0,0> 30 40 
10} because I cannot define my own objects. It wouldn't make sense 
anyway if I could because this would lead to total anarchy in the lower 
namespace. But it is still incredible difficult for me to write a parser 
that will just replace all "human {...}" with something that POVRay can 
render like a mesh. That is what I want. I don't want to touch the 
POVRay parser. I just want to get my own preprocessing done. This is 
possible with XSLT (though it sometimes looks ugly, I admit).

> Argh.. Its like arguing with someone that insists printing Bible quotes 
> on toilet paper would be sacrilegious, it has to be exactly such and such 
> font, this specific size, the paper made from only the finest rose wood 
> pulp, blah, blah, blah. Only the real argument is if the Reader's Digest 
> Condensed version leaving out all the verse names and insisting on 
> calling Moses, "the bearded guys with a stick" was the best way to get 
> the story across. lol Which is more important, that the program supposed 
> the feature everyone admits is missing, or that it was painted in the 
> most recent style? 

No, that isn't the point. Example: BASIC is a language that is capable 
of many things. But C/C++ is better. At least for professional 
programmers. No sane man would ever start to write a complex software 
project (like Mozilla or sth similar) with BASIC. So it's not a question 
of style but a question of language features. POVRay SDL lacks a lot 
features I'd like to see. So what do I do? Change POVRay? No! I cannot 
because I don't have the time. I'll rather invent some cool system that 
is able to emulate the features I'd like to have.

 > BTW, I equate XML with pointillism. Complicated,
> insanely anal and totally pointless if there is a more efficient method 
> to solve the problem. Maybe, given 50-60 years it will actually look 
> 'useful' for some programming applications, much the way pointillism more 
> or less accidentally hit on the idea for digital video, years before it 
> was remotely practical for anyone without a lot of patience and several 
> loose screws to use the idea. However, I strongly suspect it won't. lol

Do whatever you like.

> And for the 99,999th time on these news groups. Version 4.0 features are 
> not yet even technically 'in development' yet, which makes it a bit hard 
> to discuss what or how anything will be implemented in it.... Nor has the 
> team expressed a desire to discuss it and have 500 people telling them 
> not what will improve the ideas, but how they are doing it all totally 
> wrong.
> 

Exactly. And that is why I won't base my faith upon it. I never said 
that it should be done this way or that way. I just asked if someone 
would like to design an XML version of the POVRay SDL in order to gain 
customizable proprocessing levels. No change in POVRay was suggested. If 
I did, I apologize.

Besides: If that has been discussed so many times: Why don't you put it 
in the FAQ?

Regards,
Bernd Fuhrmann

Post a reply to this message